Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@docs/superpowers/specs/2026-03-12-ai-cherry-pick-conflict-resolution-design.md`:
- Line 173: The design doc's label check is inaccurate: the implementation in
pull_request_handler uses a prefix match for dynamic labels (e.g.,
"CherryPicked-from-main") rather than exact equality. Update the doc's example
expression to reflect the actual logic by replacing the equality check with a
prefix check using CHERRY_PICKED_LABEL (e.g., is_cherry_picked =
any(label.name.startswith(CHERRY_PICKED_LABEL) for label in labels)) and add a
short note that labels may be suffixed with source branches; reference the
symbols is_cherry_picked and CHERRY_PICKED_LABEL so readers know this matches
the real behavior.

In `@webhook_server/libs/handlers/labels_handler.py`:
- Around line 104-105: Replace the two separate startswith checks with a single
tuple-based startswith call: detect when label starts with either
CHERRY_PICK_LABEL_PREFIX or CHERRY_PICKED_LABEL by using
label.startswith((CHERRY_PICK_LABEL_PREFIX, CHERRY_PICKED_LABEL)) and then
return "cherry-pick" in enabled_labels; update the check in labels_handler (the
branch that references label, CHERRY_PICK_LABEL_PREFIX, CHERRY_PICKED_LABEL, and
enabled_labels) to use this combined startswith pattern.

In `@webhook_server/libs/handlers/pull_request_handler.py`:
- Around line 1080-1085: The AI-resolved early-return path leaves a stale
verified label; update the branch where is_ai_resolved is computed (using
AI_RESOLVED_CONFLICTS_LABEL) to explicitly remove/reset the VERIFIED_LABEL_STR
state before calling await self.check_run_handler.set_check_queued(...) and
returning (e.g., call the same label-removal/reset routine used in the normal
reset path or invoke the method that clears the verified label on the PR), and
add a regression test for the synchronize/reprocess path to assert that a
manually-applied verified label is removed when an AI-resolved cherry-pick is
reprocessed.

In `@webhook_server/libs/handlers/runner_handler.py`:
- Around line 952-977: The PR is being created without the
AI_RESOLVED_CONFLICTS_LABEL causing a race where the PR opened webhook may fire
before the label is applied; update gh_pr_command construction to include the
label atomically by adding the --label
{shlex.quote(AI_RESOLVED_CONFLICTS_LABEL)} flag so the label is set at creation
(affecting the gh_pr_command used by run_command), and continue to pass the
token via env; additionally, wrap all direct PyGithub property accesses in
asyncio.to_thread to avoid blocking (e.g., replace direct uses of
cherry_pick_pr.number and pull_request.title with await
asyncio.to_thread(lambda: cherry_pick_pr.number) and await
asyncio.to_thread(lambda: pull_request.title) respectively).
- Around line 1031-1033: The code is directly accessing blocking PyGithub
properties (cherry_pick_pr.number and pull_request.title) in an async handler;
wrap those attribute reads in asyncio.to_thread() to avoid blocking the event
loop. Locate usages of cherry_pick_pr.number and pull_request.title in the
handler and replace direct access with await asyncio.to_thread(lambda:
cherry_pick_pr.number) and await asyncio.to_thread(lambda: pull_request.title)
(or a small helper like read_prop(obj, "attr") run in to_thread) so logging and
any conditional logic use the awaited, non-blocking values consistently with the
existing pattern used elsewhere in the function.

In `@webhook_server/tests/test_config_schema.py`:
- Around line 820-842: Add an explicit negative test for the
resolve-cherry-pick-conflicts-with-ai flag: in the existing test function
test_ai_features_resolve_cherry_pick_conflicts_with_ai (and the similar
repository-level test around 844-866), create a config where "ai-features" sets
"resolve-cherry-pick-conflicts-with-ai": False, load it via Config() (use
Config().root_data["ai-features"]) and assert that the flag is strictly False;
mirror the setup/teardown and environment monkeypatching used in the True case
so schema regressions treating the key as truthy-only will be caught.

In `@webhook_server/tests/test_pull_request_handler.py`:
- Around line 861-866: Replace the positional boolean replacement in the three
patch.object calls that target
pull_request_handler.github_webhook.auto_verify_cherry_picked_prs so they use
the explicit keyword argument new=True instead of passing True positionally;
locate the three occurrences in the test file (the patch.object calls around the
blocks that include pull_request_handler.github_webhook, _add_label,
set_check_queued, set_check_success) and change the third argument from True to
new=True to satisfy Ruff's FBT003 rule.

In `@webhook_server/tests/test_runner_handler.py`:
- Line 1285: Replace the brittle assertion that checks
mocks.to_thread.call_count with assertions that the specific offloaded
operations were invoked: verify that mocks.to_thread was called for get_pull,
add_to_labels, and create_review_request (e.g., inspect
mocks.to_thread.call_args_list for calls that wrap those functions) so the test
asserts required behavior rather than the total call count; make the same change
for the other occurrence flagged in the comment.

In `@webhook_server/utils/github_repository_settings.py`:
- Around line 457-461: Replace the bare except Exception logging call so the
exception traceback is captured automatically: in the except block that
currently calls LOGGER.error for the GitHub App installation token retrieval
(the block referencing repository_name and the message about making sure the app
is installed), call LOGGER.exception(...) with the same descriptive message
instead of LOGGER.error (or LOGGER.error(..., exc_info=True)); this will include
the stack trace and preserve the existing text about the app installation.

---

Outside diff comments:
In `@examples/config.yaml`:
- Around line 128-132: The example turns the
resolve-cherry-pick-conflicts-with-ai flag on by default; change the ai-features
sample so resolve-cherry-pick-conflicts-with-ai is set to false (matching the
schema/default) and update its inline comment to indicate this feature is opt-in
and defaults to false, referencing the ai-features section and the
resolve-cherry-pick-conflicts-with-ai key so users copying the example won't be
unintentionally opted into AI-driven conflict resolution.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/superpowers/plans/2026-03-12-ai-cherry-pick-conflict-resolution.md`:
- Around line 47-79: The plan and schema snippet are outdated: instead of adding
a boolean `resolve-cherry-pick-conflicts-with-ai` to the `ai-features` $defs,
update `webhook_server/config/schema.yaml` so the new property is an object with
`enabled` (boolean, default false) and `timeout-minutes` (integer, default as
used in shipped code) under `$defs` → `ai-features` (insert after
`conventional-title` and before `required:`), and adjust the procedural steps in
the plan to match the current workflow (stage changes with `git add -u` and
reference that PR labeling is applied via the PyGithub-based code path rather
than expecting `gh pr create` to apply labels).

In `@webhook_server/libs/handlers/runner_handler.py`:
- Around line 702-710: The code assumes cherry_pick_ai_config is a mapping and
calls .get(), which raises AttributeError when the YAML value is a scalar
(bool); update the logic around ai_config and cherry_pick_ai_config in
runner_handler.py to first inspect types (use isinstance(cherry_pick_ai_config,
dict)), treat a boolean True as equivalent to {"enabled": True}, and only call
.get("enabled") when cherry_pick_ai_config is a dict; apply the same
normalization at the other occurrence referenced around line 739 so scalar YAML
values like resolve-cherry-pick-conflicts-with-ai: true remain
backward-compatible and do not cause attribute errors.

In `@webhook_server/tests/test_config_schema.py`:
- Around line 820-823: The test function
test_ai_features_resolve_cherry_pick_conflicts_with_ai (and the other test with
a boolean positional) uses a boolean positional parameter `enabled: bool` which
triggers Ruff FBT001; make the boolean parameter keyword-only by adding a bare
`*` before `enabled` in the function signature (e.g., change the signature to
include `*, enabled: bool`) so pytest.parametrize still works while satisfying
the linter.

In `@webhook_server/tests/test_runner_handler.py`:
- Around line 1581-1589: The test test_cherry_pick_ai_feature_disabled_fallback
currently omits the resolve-cherry-pick-conflicts-with-ai setting so it
exercises the "missing config" path; update the test's
runner_handler.github_webhook.ai_features to include
"resolve-cherry-pick-conflicts-with-ai": {"enabled": False} (or alternatively
rename the test to reflect the missing-config scenario) so
RunnerHandler._resolve_cherry_pick_with_ai() actually exercises the
enabled:false branch.

In `@webhook_server/utils/constants.py`:
- Line 25: The new constant AI_RESOLVED_CONFLICTS_LABEL was added but not mapped
into LABEL_CATEGORY_MAP so LabelsHandler.is_label_enabled() treats it as unknown
and allows it even when its category is disabled; update LABEL_CATEGORY_MAP to
include AI_RESOLVED_CONFLICTS_LABEL mapped to the appropriate category (e.g.,
the same category as cherry-pick) so the label gating logic in
LabelsHandler.is_label_enabled() will respect labels.enabled-labels; also ensure
any other related static labels declared around the same area (the labels at the
other entries mentioned) are likewise categorized.

In `@webhook_server/utils/github_repository_settings.py`:
- Around line 442-461: Move local configuration reads and parsing out of the
broad try/except: open and read the PEM file
(config_.data_dir/webhook-server.private-key.pem), extract github_app_id from
config_.root_data, and split repository_name with repository_name.split("/",
maxsplit=1) outside any exception handler so
FileNotFoundError/KeyError/ValueError propagate. Wrap only the PyGithub API
calls (creating Auth.AppAuth / GithubIntegration, calling
GithubIntegration.get_repo_installation and get_access_token) in a try/except
that catches GithubException (or the specific PyGithub exception type) and
returns None for the “app not installed” case; do not catch Exception broadly
and do not suppress local config errors. Ensure identifiers referenced are
Auth.AppAuth, GithubIntegration, get_repo_installation, get_access_token,
installation, and LOGGER.

---

Outside diff comments:
In `@webhook_server/tests/test_pull_request_handler.py`:
- Around line 820-827: The test currently uses
assert_called_once()/assert_called_once_with() on AsyncMock objects
(mock_add_label, mock_set_success) after calling
pull_request_handler._process_verified_for_update_or_new_pull_request, which
only verifies a coroutine was created but not awaited; replace those assertions
with the AsyncMock-specific await-aware assertions (e.g., assert_awaited_once()
/ assert_awaited_once_with()) for mock_add_label and mock_set_success (and apply
the same change to the other test blocks at the noted ranges) so the tests fail
if the code stops awaiting these async calls.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@webhook_server/tests/test_github_repository_settings.py`:
- Around line 782-845: Remove the unused LOGGER patch from
test_get_repository_github_app_token_success (or use the injected mock_logger
inside the test) to eliminate the dead-fixture warning, and avoid a
hardcoded-token literal by setting the mocked token via a non-literal expression
(e.g. mock_access_token.token = "fake" + "-token" or
configure_mock(token="fake-token")) before calling
get_repository_github_app_token so the test still asserts the expected value
without triggering secret-detection rules.